fix(client): skip the SSE fallback when the server/discover probe is rejected with 400/404 - #1855

Summary

AutoDetectingClientSessionTransport attempts the SSE fallback when the SEP-2575 server/discover probe is rejected with 400 or 404. Neither status says anything about which transport the peer speaks: a server predating SEP-2575 rejects the session-less server/discover POST the same way whether it is Streamable-HTTP-only or SSE-only (400 when it cannot parse the request, 404 when it requires Mcp-Session-Id on every non-initialize POST).

McpClientImpl.ConnectAsync already reads exactly these two statuses as "this server requires the initialize handshake" and retries with initialize on the same transport — and that attempt still falls back to SSE. So the SSE GET spent during the probe is always discarded:

• a Streamable-HTTP-only server predating SEP-2575 pays a wasted GET on every connect, and logs streamable HTTP transport failed with status code NotFound, falling back to SSE transport at Information for what is settled protocol negotiation rather than a failure;
• an SSE-only server is reached either way — one POST later instead of one GET earlier.

This skips the fallback for that one case, scoped to the server/discover probe and to the two statuses ConnectAsync acts on. Every other failure keeps the existing behavior.

Observable behavior this addresses

Datadog's managed MCP server (datadog-mcp 1.0.0, https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp) is a Streamable-HTTP-only server predating SEP-2575:

Every connect currently costs discover-POST -> SSE-GET (405) -> initialize-POST, and logs the misleading fallback line. With this change it is discover-POST -> initialize-POST.

Relationship to existing work

• Related to SDK Client: ConnectAsync discover→initialize fallback unreachable when AutoDetect transport fails with HttpRequestException #1848. That issue's "Fix 1" — catching HttpRequestException 400/404 in ConnectAsync — is already in main, which is what makes the initialize retry reachable and therefore makes the SSE attempt redundant here. This PR does not touch the TryReadJsonRpcErrorAsync content-type gap that SDK Client: ConnectAsync discover→initialize fallback unreachable when AutoDetect transport fails with HttpRequestException #1848 also raises.
• Adjacent to open PR fix: fall back to SSE when AutoDetect probe gets 405 with JSON-RPC error body #1849, which adds a fallback for 405-with-JSON-RPC-body. The two are orthogonal (different statuses, different body classification) but edit the same method, so whichever lands second needs a small rebase.

Verification

--filter 'FullyQualifiedName~HttpClientTransportAutoDetectTests': 13 passed on both net9.0 and net10.0 (9 pre-existing + 4 new). net8.0 could not run locally — no .NET 8 runtime on this machine.

Full ModelContextProtocol.Tests on net10.0: 2361 passed, 2 failed — both DockerEverythingServerTests, which fail identically on unmodified main in this environment (container startup, not transport). ModelContextProtocol.AspNetCore.Tests on net10.0: 615 passed, 0 failed.

DockerEverythingServerTests.ConnectAndReceiveMessage_EverythingServerWithSse — a real SSE-only server reached over AutoDetect — passes with the change, and the second new test pins that same path at the transport level.

New tests:

• AutoDetectMode_SkipsSseFallback_WhenDiscoverProbeIsRejected (Theory: 404, 400) — no GET is issued, the original status surfaces, and no fallback line is logged.
• AutoDetectMode_StillFallsBackToSse_WhenInitializeFollowsRejectedDiscoverProbe — an SSE-only server is still reached, via the initialize retry.
• AutoDetectMode_FallsBackToSse_WhenDiscoverProbeFailsWithUnrelatedStatus (415) — the skip stays scoped to 400/404.

AI assistance disclosure: AI was used to discover this opportunity and draft the change and text. The submission was checked against the prepared artifact and recorded verification evidence.